This code makes Lintian unhappy. But we are really not using it, it only
gets inserted when building the online doc.
Anyways the best way to calm down Lintian is to simply remove it.
From bb1006b789f4ed0183b6ca668a45f75243879cb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?M=C3=A5rten=20Nordheim?= <marten.nordheim@qt.io>
Date: Tue, 25 Jun 2024 17:09:35 +0200
Subject: [PATCH] HTTP2: Delay any communication until encrypted() can be
responded to
We have the encrypted() signal that lets users do extra checks on the
established connection. It is emitted as BlockingQueued, so the HTTP
thread stalls until it is done emitting. Users can potentially call
abort() on the QNetworkReply at that point, which is passed as a Queued
call back to the HTTP thread. That means that any currently queued
signal emission will be processed before the abort() call is processed.
In the case of HTTP2 it is a little special since it is multiplexed and
the code is built to start requests as they are available. This means
that, while the code worked fine for HTTP1, since one connection only
has one request, it is not working for HTTP2, since we try to send more
requests in-between the encrypted() signal and the abort() call.
This patch changes the code to delay any communication until the
encrypted() signal has been emitted and processed, for HTTP2 only.
It's done by adding a few booleans, both to know that we have to return
early and so we can keep track of what events arose and what we need to
resume once enough time has passed that any abort() call must have been
processed.
Conflict resolution: adapt to Qt 5 code supporting SPDY as well.
From 95064c35826793c5d6a4edff9fa08ad308b047bb Mon Sep 17 00:00:00 2001
From: Timur Pocheptsov <timur.pocheptsov@qt.io>
Date: Tue, 20 Jul 2021 08:16:28 +0200
Subject: [PATCH] H2: emit encrypted for at least the first reply, similar to
H1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The DNS Records are variable length and encode their size in 16 bits
before the Record Data (RDATA). Ensure that both the RDATA and the
Record header fields before it fall inside the buffer we have.
Additionally reject any replies containing more than one query records.
For the comparison with max() - 32 to trigger, on 32-bit platforms (or
Qt 5) signed interger overflow would have had to happen in the
addition of the two sizes. The compiler can therefore remove the
overflow check as dead code.
On Qt 6 and 64-bit platforms, the signed integer addition would be
very unlikely to overflow, but the following truncation to uint32
would yield the correct result only in a narrow 32-value window just
below UINT_MAX, if even that.
Fix by using the proper tool, qAddOverflow.
Manual conflict resolutions:
- qAddOverflow doesn't exist in Qt 5, use private add_overflow
predecessor API instead
Since ODBC does not have a direct way finding out if unicode is
supported by the underlying driver the ODBC plugin does some checks. As
a last resort a sql statement is executed which returns a string. But
even this may fail because the select statement has no FROM part which
is rejected by at least Oracle does not allow. Therefore add another
query which is correct for Oracle & DB2 as a workaround. The question
why the first three statements to check for unicode availability fail
is still open but can't be checked since I've no access to an oracle
database.
When we fixed the callers of toSQLTCHAR() to use the result's size()
instead of the input's (which differ, if sizeof(SQLTCHAR) != 2), we
exposed callers to the append(0), which changes the size() of the
result QVLA. Callers that don't rely on NUL-termination (all?) now saw
an additional training NUL.
Fix by not NUL-terminating, and changing the only user of SQL_NTS to
use an explicit length.
Unless "." (or the empty string) is in $PATH, we're not supposed to find
executables in the current directory. This is how the Unix shells behave
and we match their behavior. It's also the behavior Qt had prior to 5.9
(commit 28666d167aa8e602c0bea25ebc4d51b55005db13). On Windows, searching
the current directory is the norm, so we keep that behavior.
This commit does not add an explicit check for an empty return from
QStandardPaths::findExecutable(). Instead, we allow that empty string to
go all the way to execve(2), which will fail with ENOENT. We could catch
it early, before fork(2), but why add code for the error case?
See https://kde.org/info/security/advisory-20220131-1.txt
When multiple globs match, and the result from magic sniffing is
unrelated to any of those globs, globs have priority and one of them
should be picked up.
* Non-maintainer upload by the LTS Security Team.
* CVE-2024-39936: issue in HTTP2. Code to make security-relevant
decisions about an established connection may execute too early,
because the encrypted() signal has not yet been emitted and
processed.
* Add Salsa-CI configuration
* Add git-buildpackage configuration
* Add lintian overrides for test binary data
projects / qtbase-opensource-src.git / log